Dieser Kurs widmet sich der Erleichterung der Arbeit mit der Workbench, der Verbesserung ihrer Funktionen und auch ihrer Verschönerung. Natürlich gibt es unzählige Programme, Patches usw. die dazu beitragen (wollen). Ich werde nicht auf alle eingehen können, hoffe aber, daß hier ein paar Anregungen und Tips bei sein werden, die noch nicht allen bekannt sind.
Bei vielen Programmen gibt es spezielle Formen des Nutzungsrechtes. Es kann sich z.B. um Shareware, Cardware o.ä. handeln. Ich gehe darauf nicht in jedem Fall explizit ein. Eine Demoversion ist so gut wie immer frei erhältlich. Als Quelle fungiert das AMINET.
Verschiedene Funktionen sind auch in Multifunktions-Commodities integriert, im Teil 6 werde ich auf ein Beispiel hierfür eingehen.
Der Kurs setzt sich aus folgenden Artikeln zusammen: | |
| #1 #2 #3 #4 #5 #6 |
...und ohne weitere Umstände geht es endlich an den nächsten Kursteil.
Heute dreht er sich um kleine Hilfprogramme, die auf der System-Partition unter `C:` am besten aufgehoben sind. Sie haben allesamt eine Größe von max. 10 KByte und liegen vielfach sogar weit darunter.
Geht es Ihnen nicht manchmal auch so? Sie haben viele verschiedene Commodities und Patches (vielleicht sogar manche auf Grund dieses Kurses) installiert und plötzlich gibt es unerklärliche Phänomene auf Ihrem Rechner oder er stürzt gar ab?
Jetzt will man das Problem möglichst eingrenzen, denn sicher liegt das wieder an einem dieser unsauber programmierten Hacks, die das Leben so angenehm machen. ;) Aber an welchem? Und nun kann man von einer fertig gebooteten Workbench nicht alle einzeln ein- und ausschalten, wie man will, denn es kommen ständig Requester, die darauf aufmerksam machen, daß dieser und jener Patch nicht aus dem Speicher entfernt werden kann.
Das ist nur eine der Situationen, bei denen es notwendig werden kann, Patches zu deaktivieren. Abhilfe schafft da "PatchControl". Es ist jeweils im Archiv des MultiCommodities MCP enthalten, aber seit einiger Zeit auch separat im Aminet zu beziehen.
Der Trick besteht darin, daß "PatchControl" in der Startup-Sequenz vor allen anderen Patches aufgerufen wird. Dann sind später alle Patches problemlos und sauber aus dem System entfernbar.
Bleiben wir bei der Startup-Sequenz.
Mit "BootSelector" wird in `S:` ein neues Verzeichnis "Startup's" angelegt, in dem sich sechs verschiedene Startup-Sequenzen befinden. Für jede Maustastenkombination eine - es werden folglich Dreitasten-Mäuse unterstützt. Wenn man beim Booten dann die jeweilige(n) Taste(n) gedrückt hält, wird jeweils eine individuelle, den jeweiligen Bedürfnissen angepaßte Workbench gestartet.
"RamPatch", wird ebenfalls von der Startup-Sequenz aus aufgerufen. Jetzt wird korrekt angegeben, wieviel Speicher frei ist und die Ram-Disk nicht mehr generell als `100% belegt` gekennzeichnet.
Wer gelegentlich oder auch immer Probleme mit seiner Hardware-Uhr hat, indem ihre gepufferte Zeit öfter als gewöhnlich von bestimmten Programmen zerschossen wird oder die Uhr auch einfach gar nicht mehr geht, für den ist "ClockCheck" oder eines der äquivalenten Programme das Richtige.
"ClockCheck" überprüft beim Booten, ob die ausgelesene Systemzeit ungewöhnlich stark von der des letzten Hochfahrens abweicht. Wenn ja, öffnet sich ein Requester, der fragt, ob die Zeit so korrekt ist. Wenn sie es tatsächlich ist und man dies bestätigt, wird sie als Vergleichsobjekt für die nächsten Bootvorgänge abgespeichert.
Sollte die Zeit nicht stimmen, wird der Uhrzeit-Einsteller der WB geöffnet und man kann sie nachbessern. Nach diesem Prinzip öffnet das Programm also tatsächlich nur seinen Requester, wenn eine größere Differenz der aktuell geltenden zur zuletzt abgespeicherten Zeit festgestellt werden.
Ursache für manch seltsame Alerts oder in extremen Fällen sogar für Guru`s kann Stackmangel gewisser Programme sein. Manche Commodities patchen die selben Libraryroutinen und erhöhen dann teilweise die Stackspeichermenge, die bei deren Aufruf benötigt wird. Abhilfe schafft hier "StackAttack".
Das waren einige kleinere Programme, die, wenn benötigt, von der Startup-Sequenz aufgerufen werden müssen.
Wer häufig ohne Startup-Sequenz bootet und dann doch noch die WB aufrufen will, kann dies mit dem Befehl "GoWB" ein klitzekleines bißchen einfacher und schneller, denn der genügt, um die WB zu laden und das CLI-Fenster zu schließen. :)
Wenn Programme von der Shell aufgerufen werden, haben sie oft ein einnehmendes Wesen und geben sie nicht wieder frei. Die Shells bleiben blockiert und hängen auf der Workbench `herum`.
Mit "BackEx" werden Programme als Hintergrundprozeß gestartet und dieselbe Shell steht nach dem Start des Programmes wieder zur Verfügung.
"DTView" ist ein winziger Datatype-Anzeiger, der recht nützlich werden kann und z.B. leicht mit DirectoryOpus oder Toolmanager verknüpfbar ist. Er öffnet einen Filerequester, von dem man komfortabel die anzuzeigenden Bilder anwählen kann. In Sachen Anzeigequalität, sowie Geschwindigkeit ist man dann natürlich auf die jeweils installierten Datatypes angewiesen.
"UnPacker" ist äußerst hilfreich, denn man braucht sich nach seiner Installation nicht mit den zahlreichen unterschiedlichen Optionen verschiedener, teilweise selten benutzter, Packer herumschlagen, wenn man mal eine mit ihnen gepackte Datei decrunchen will.
Die wichtigsten, inklusive DiskArchiver, sind hier bereits vorkonfiguriert. Lediglich das Vorhandensein der Packer/Entpacker in `C:` oder wo immer man es definiert, wird vorausgesetzt. Auch "UnPacker" läßt sich leicht in z.B. DOpus einbinden.
Alle Benutzer von AGA werden gelegentlich damit konfrontiert, bestimmte Features ausschalten und/oder ein altes System vorgaukeln zu müssen, wenn ein älteres Programm gestartet werden soll, das ohne diese Maßnahmen Probleme macht.
Neben vielen größeren Degradern mit vielen Einstellmöglichkeiten, genügen häufig auch kleine, aber feine. So z.B. "FixAga", das einen Filerequester aufruft, in dem man das zu startende Programm auswählen kann oder "KillAga", das von der Shell oder dem CLI aus zu starten ist.
Probleme treten aber oft schon auf, wenn man solcherlei Programme, Demos oder Spiele (manche von ihnen sind sogar AGA-Versionen) von seiner Workbench aus starten will, weil die WB nicht unter einer HighRes oder LowRes-Auflösung, sprich PAL, läuft.
Mit dem Kommando "RunPAL" und dem Programmnamen als Argument, werden die Programme in dem PAL-Modus gezwungen, ohne daß man größere Konfigorgien zur temporären Veränderung seines Bildschirmmodus starten muß.
Vielfach unbekannt ist ein Fehler in der Hardware des Amiga 4000-030, der nur bei ihm auftritt. Bei manchen Spielen und Demos war ein Hacken im Timing zu beobachten, der ihre Benutzung unmöglich machte. Das kleine "DTack" behebt den Fehler.
Es ist also doch einiges zusammengekommen, so daß ich die Kursplanung dahingehend verändert habe, daß es sechs reguläre Teile werden.
Bleiben Sie mir treu! In dem Fall sehen wir uns bei den "Sonstigen
Helferlein" wieder.
![]() |
Inhaltsverzeichnis | ![]() |
©`98Der AmZeiger |